The present invention relates in general to the field of computers and other data processing systems, including hardware, software and processes. More particularly, the present invention pertains to the management of the resources of such a system using rules and/or policies. Still more particularly, the present invention enables custom applications to embed rule authoring capabilities.
Most efforts to integrate rules engines (such as the design options for rule engine integration described in “Business Process Automation Made Easy With Java, Part 2,” by Ahmed Abulsurour and Siva Visveswaran, and accessible at http://www.javaworld.com/javaworld/jw-10-2002/jw-1018-process2.html), focus on the runtime aspects of integration. Note also that “Business Process Automation Made Easy With Java, Part 1,” also by Ahmed Abulsurour and Siva Visveswaran, and accessible at http://www.javaworld.com/javaworld/jw-09-2002/jw-0906-process.html, shows external components communicating with the rule engine at runtime, but does not discuss integration between the application where the rule will be invoked and the rule authoring environment.
Another prior art document on rule editing is found at http://www.fairisaac.com/Fairisaac/Solutions/Enterprise+Decision+Management/Business+rules/Blaze+Advisor/, which describes highlights of “Blaze Advisor” from Fair Isaac Corporation. This document mentions that rule editing is part of an “integrated development environment,” but does not discuss how rule authoring may be embedded in an application such as Lotus Notes™, Lotus Domino™ (both from International Business Machines, Inc.), or an expense payroll application, at least not without constructing custom forms as mentioned in the documentation.
JRules™, from ILOG, Inc., also integrates its rule editing capabilities in an integrated development environment such as “Rule Studio” (see http://www.ilog.com/products/jrules/), instead of surfacing those rule editing capabilities through the end user application.
Many existing business rules engines provide a standalone user interface for authoring rules or integrate those rule editing capabilities into an IDE. To use such an application, however, the business rule author must leave the application to which the rules apply and go to an Integrated Development Environment (IDE) or standalone rule administration page.
More recently, the business rule author is a policy author writing rules to codify policies. In this case, to author a policy rule, the user must exit the application to which the policy applies. For instance, the business user may be writing a rule to decide what travel expenses must be sent to a manual authorization process. The business user must leave the expense administration application and use a business rules application to administer the rules guiding this policy. At best, a link is provided to the rule administration User Interface (UI) from the expense administration UI.
Other systems have used custom built embedded rule capabilities, such as rule-based routing of mail to folders. While this capability is part of the mail application, it is not part of a general purpose rules engine. Thus, rules written in the mail application cannot easily be re-used by other applications.
Some previous rule engine implementation have allowed for projects. A project could include the definitions of business vocabulary. However, this does not allow for multiple applications which might cooperate in a single project sharing parts of the business vocabulary. For instance, web content rules may exist in the same project as rules for portal navigation, each using different business vocabulary. While some applications might have overlapping business vocabulary, if a rule includes conditions dependant on attributes of the content, then that rule would not be available to use in policies of different applications. Using a project based approach completes segments rules and minimizes any value gained from a common rule infrastructure. Aside from projects, another possible implementation is to have multiple instances of the rule editor/rule engine, each configured with different available objects. Again, this approach completely segments the rules and minimizes any benefit from a common infrastructure.
Some rule engines require the user to explicitly state the input and output of a rule type. By specifying the input and output when defining the rule type, these implementations fix a set of allowed business vocabulary for a given rule type, not allowing it to be customized based on the application using the rule type or the context of the rule being invoked. They also require the author of the rule to know what inputs and output will be available when the rule is executed.
While the concept of a rule mapping, or an association between a rule and a place that rule is used, is known in the prior art, the concept of allowing a calling application to manage the rule mapping without indirection (e.g., through the use of content spots or “point of variability—pov”) is heretofore unknown.